This invention relates to testing of software applications. As software development is moving to a distributed, multi-tiered and heterogeneous computing environment, the Java™ programming language has become one of the most popular programming languages for developing component-based, multi-tiered, distributed applications. For example, the J2EE (Java™ 2 Enterprise Edition) technology has integrated application clients and applets, web components (JSP and servlets), and Enterprise JavaBeans™ (EJB™) components. As is well-known to computer program developers, in a distributed environment it is crucial that different components are assembled cohesively to produce one integrated application.
Before this assembly takes place, it is necessary to properly unit test each component independently. Unit testing each component in isolation significantly reduces bugs and helps to ensure high-quality software. Unit testing is a piece of code written by a developer that exercises a very small, specific area of functionality of the code being tested. A common way of performing unit testing of a client-side Java™ application is to use the JUnit test framework. The JUnit test framework offers several benefits, such as simple framework for writing automated, self-verifying tests in Java™, support for test assertions, test suite development immediate test reporting, and has for these and many other reasons become a very popular testing tool.
However, it is typically difficult to devise database (or other external data repository) dependent JUnit tests. The reason is that the database will hold a complex graph of objects represented in the form of database rows in many different tables. The JUnit test writer must struggle to alter the database to a state where the database holds all of those rows representing the objects in exactly the right state before a tests runs, in order to properly perform the JUnit test. Similarly, the test writer may also have to figure out how to restore the database to the state the database was in right before the test was run. This is important as it may be necessary to run a single test multiple times, or to run a sequence of multiple, different tests. Furthermore, proper JUnit tests must never depend on other tests having run successfully. In other words, all tests must be able to run completely independently.
Various attempts have been made to achieve the necessary state changes for databases prior to running the texts. Some proposed solutions include using Java™ code to manually create all the objects as part of the test setup, using scripts to setup the database, or loading backup copies of the database. Manually creating all objects requires writing complex Java™ code over and over for each test. Using scripts or loading backup copies are typically very inconvenient methods, as they are slow and cumbersome to the point that they are often not practical, since the JUnit tests depend on the particular database (or other external source) that is used. Thus, it would be desirable to have a more flexible way to devise database (or other external data repository) dependent JUnit tests.